Electronic commerce network with mobile transactions

ABSTRACT

A commerce network that processes a mobile transaction detects a mobile device of a user entering a store, the user having a corresponding user account that includes one or more tenders. The network creates a payment token corresponding to the detecting and registers it with the store. The network receives a personal identification number (“PIN”) from the user and authenticates the PIN. The network receives a basket of goods of one or more items selected by the user for purchase, the basket of goods including line level data for the items. The network then selects one or more payment tenders from the one or more tenders based at least on the line level data and validates and authorizes the selected payment tenders.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims priority of Provisional Patent Application Ser.No. 61/668,254, filed on Jul. 5, 2012, Provisional Patent ApplicationSer. No. 61/668,255, filed on Jul. 5, 2012, and Provisional PatentApplication Ser. No. 61/755,135, filed on Jan. 22, 2013, the contents ofeach of which is hereby incorporated by reference.

FIELD

One embodiment is directed generally to a computer system, and inparticular to an electronic commerce network and system.

BACKGROUND INFORMATION

Electronic commerce, or “e-commerce”, is generally considered the buyingand selling of a product or service over electronic systems or a“commerce network” such as the Internet and other computer networks.Electronic commerce can include functionality such as mobile commerce,electronic funds transfer, supply chain management, Internet marketing,online transaction processing, electronic data interchange (“EDI”),inventory management systems, and automated data collection systems.Electronic commerce and a commerce network as a core function providesthe exchange of data to facilitate the financing and payment aspects ofbusiness transactions.

The mobile commerce aspect of a commerce network, also referred to asmobile transactions, mobile payment, and mobile wallet, generally refersto payment services operated under financial regulation and performedfrom or via a mobile device such as a smartphone. Instead of paying withcash, check, or credit cards, a user can use a mobile phone to pay for awide range of services and digital or hard goods.

There are many known models that can be used for mobile commerce. Thesemodels include Short Message Service (“SMS”) based transactionalpayments in which the user sends a payment request via an SMS textmessage and a premium charge is applied to the user's phone bill oronline wallet. Another model is direct mobile billing in which the useruses the mobile billing option during checkout at an e-commerce site,such as an online gaming site, to make a payment. After authenticationtypically involving a personal identification number (“PIN”) and apassword, the consumer's mobile account is charged for the purchase.

Another known model is mobile web payments in which the user uses webpages displayed or additional applications downloaded and installed onthe mobile phone to make a payment using Wireless Application Protocol(“WAP”). Still another model is contactless Near Field Communication(“NFC”) in which a consumer using a special mobile phone equipped with asmart card waves the phone near a reader module. Most NFC transactionsdo not require authentication, but some require authentication using aPIN before the transaction is completed. The payment is deducted from apre-paid account or charged to a mobile or bank account directly.

Each of these known models, and other known mobile commerce models, havepotential disadvantages, including security concerns, lack offlexibility in that the user may be locked into a specific vendor orfinancial institution, and being difficult to use, especially whenmultiple or alternative forms of tender are involved in a transaction.As a result, no single model predominates the mobile commercemarketplace.

SUMMARY

One embodiment is a commerce network that processes a mobiletransaction. The network detects a mobile device of a user entering astore, the user having a corresponding user account that includes one ormore tenders. The network creates a payment token corresponding to thedetecting and registers it with the store. The network receives apersonal identification number (“PIN”) from the user and authenticatesthe PIN. The network receives a basket of goods of one or more itemsselected by the user for purchase, the basket of goods including linelevel data for the items. The network then selects one or more paymenttenders from the one or more tenders based at least on the line leveldata and validates and authorizes the selected payment tenders.

BRIEF DESCRIPTION OF THE DRAWINGS

Further details, advantages, and modifications will become apparent fromthe following detailed description of embodiments of the invention,which is to be taken in conjunction with the accompanying drawings, inwhich like numerals denote like elements.

FIG. 1 is an overview diagram of an electronic commerce network andassociated peripheral devices in accordance with embodiments of thepresent invention.

FIG. 2 is a block diagram of a computer server/system that can implementthe network of FIG. 1, and well as any of the associated peripheraldevices of FIG. 1, in accordance with an embodiment of the presentinvention.

FIG. 3 is an overview diagram illustrating a user initiating thefunctionality of the network of FIG. 1 in accordance with oneembodiment.

FIG. 4 is an overview diagram illustrating a merchant initiating thefunctionality of the network of FIG. 1 in accordance with oneembodiment.

FIG. 5 illustrates a user being checked into a store with a storeaccount in accordance with one embodiment.

FIG. 6 illustrates a POS client at the merchant and using the merchantaccount to checkout the user in accordance with one embodiment.

FIG. 7 further illustrates the checkout process based on a basket ofgoods selected by the user in accordance with one embodiment.

FIG. 8 illustrates the functionality of a transaction engine inaccordance with an embodiment of the present invention.

FIG. 9 illustrates the functionality of the transaction engine withmultiple items and multiple payment/tender options in accordance with anembodiment of the present invention.

FIG. 10 is a flow diagram of the functionality of the commerce networkmodule of FIG. 1 when providing mobile commerce and conducting a mobiletransaction in accordance with one embodiment.

DETAILED DESCRIPTION

One embodiment is an electronic commerce network that facilitates mobiletransactions. The commerce network allows a user with a mobile device toenter a store, and make a purchase of a basket of goods. The purchasecan be made using one or more different tender instruments, includingelectronic coupons, gift certificates, debit cards, credit cards, etc.The commerce network authenticates the user, and can determine the bestmix of tender instruments to use for the particular basket of goods.

FIG. 1 is an overview diagram of an electronic commerce network 100 andassociated peripheral devices in accordance with embodiments of thepresent invention. Network 100 is implemented by one or more servercomputers (“servers”) and is connected to the peripheral devices via theInternet, or other telecommunication means, to provide the functionalitydisclosed in detail below. Network 100 includes and implements at leastone user/customer account 102, at least one merchant/retailer account104 and at least one issuer account 106. Network 100 further includesone or more engines 110, including a transaction engine and a businessoptimization engine, as described in more detail below. Thefunctionality of network 100 in one embodiment is accessible by any userover the Internet using a browser or any other interface method. Theinterface method can include application programming interfaces (“API”s)107, 122 and 132.

Network 100 functions as a fabric that connects accounts for theprincipal parties of commerce—users, merchants, and issuers of tender.Network 100 enables fluid commerce by making accounts online andaccessible. These accounts can be joined to facilitate rich interactionsincluding purchase transactions, offer targeting/delivery, and otherpersonalized experiences. The accounts are made accessible by theassociated peripheral devices, including clients such as user clients108, 109, and merchant-based clients such as point of sale (“POS”)client 120 and management client 121, which extend the reach of network100 to a user's computer 109, mobile device 108, the merchant's countervia POS 120, and any other device that can interface with network 100.

FIG. 2 is a block diagram of a computer server/system 10 that canimplement network 100 of FIG. 1, and well as any of the associatedperipheral devices of FIG. 1, in accordance with an embodiment of thepresent invention. Although shown as a single system, the functionalityof system 10 can be implemented as a distributed system. Further, thefunctionality of network 100 can be implemented by a single system 10,or by multiple systems 10. Further, any of the devices/functionalityshown in FIG. 1 can be implemented by one or more system 10s. Finally,all elements shown in FIG. 2 are not required in any implementation ofany portion of network 100.

System 10 includes a bus 12 or other communication mechanism forcommunicating information, and a processor 22 coupled to bus 12 forprocessing information. Processor 22 may be any type of general orspecific purpose processor. System 10 further includes a memory 14 forstoring information and instructions to be executed by processor 22.Memory 14 can be comprised of any combination of random access memory(“RAM”), read only memory (“ROM”), static storage such as a magnetic oroptical disk, or any other type of computer readable media. System 10further includes a communication device 20, such as a network interfacecard, to provide access to a network. Therefore, a user may interfacewith system 10 directly, or remotely through a network or any otherknown method.

Computer readable media may be any available media that can be accessedby processor 22 and includes both volatile and nonvolatile media,removable and non-removable media, and communication media.Communication media may include computer readable instructions, datastructures, program modules or other data in a modulated data signalsuch as a carrier wave or other transport mechanism and includes anyinformation delivery media.

Processor 22 is further coupled via bus 12 to a display 24, such as aLiquid Crystal Display (“LCD”). A keyboard 26 and a cursor controldevice 28, such as a computer mouse, are further coupled to bus 12 toenable a user to interface with system 10.

In one embodiment, memory 14 stores software modules that providefunctionality when executed by processor 22. The modules include anoperating system 15 that provides operating system functionality forsystem 10. The modules further include a commerce network module 16 thatprovides the functionality of commerce network 100 of FIG. 1, asdisclosed in more detail below. System 10 can be part of a largersystem, such as a database management system or a financial managementsystem. Therefore, system 10 will typically include one or moreadditional functional modules 18 to include the additionalfunctionality. A database 17 is coupled to bus 12 to provide centralizedstorage for modules 16 and 18.

Referring again to FIG. 1, each user of network 100 is represented byuser account 102. User account 102 holds basic profile information,global and merchant specific payment preferences, and any number andtype of tender instruments including debit cards, private label cards,gift cards, bank accounts, coupons, offers, loyalty cards, loyaltypoints, etc. Users may access and manage this information through arange of user clients such as clients 108, 109. The user clients can beany device that allows access to network 100 over the Internet or othernetwork, and may include an Internet browser. The clients may include aweb page, mobile applications, and tablet interfaces which enable usersto add/delete tender instruments, view a transaction history, andperform a range of other account management functions. User account 102facilitates the collection and management of any tender type from anyplatform (e.g., web page, mobile, social) by the user. User account 102also enables the seamless sharing of these tender instruments with themerchant at the time of transaction via network 100.

Each merchant using network 100 creates a merchant account 104 thatrepresents the merchant on network 100. Merchant account 104 holds basicinformation such as store address/location(s) and merchant acquiringinformation that defines how payment should flow to the merchant.Merchant account 104 also holds detailed user and store leveltransaction information and analytics. Finally, merchant account 104contains information about merchant clients such as POS client 120 andmanagement client 121 which may access and interact with merchantaccount 104. An authorized merchant POS client such as client 120 mayconnect to network 100 via POS or merchant APIs 122 to facilitate userauthentication and transaction settlement from the POS. Similarly,merchant management client 121 can interact with merchant account 104via a web page or tablet interfaces to access real-time analytics,configure account settings, or interact with engines 110, including thebusiness optimization engine. The business optimization engine allowsmerchants to tailor rich offers, loyalty rewards, and other promotionsto individual users or user segments to assist with customer acquisitionand retention.

Each issuer 130 of tender using network 100 has a corresponding issueraccount 106. An issuer account 106 may include an authorization policy,an authorization mechanism and a settlement mechanism for each tendertype the issuer supports. The authorization and settlement mechanismsspecified for each tender are executed by the transaction engine as itprocesses a transaction. While traditional forms of tender use existinginfrastructure for authorization and settlement, newer forms of tendermay use new authorization and settlement mechanisms. Therefore, in oneembodiment the issuer API 132 includes new authorization and settlementmechanisms, including authorization by web services and directsettlement.

As discussed, embodiments interconnect users and merchants/retailers toenable complex transaction processing and other functionality. Toinitiate the functionality of network 100, in one embodiment a userdownloads an application to a mobile device and sets up a user account102. An account may be set up through a website, a mobile application,or any other method.

FIG. 3 is an overview diagram illustrating a user initiating thefunctionality of network 100 of FIG. 1 in accordance with oneembodiment. In one embodiment, the user could use a website via userclient/computer 109 to create a user account 102, set up the passwordfor the account, and create a personal identification number (“PIN”).The user could also use the website to populate the user account 102with a debit card 303, a loyalty card 304 and a coupon 305. Other tenderinstruments are possible. The user can then download a “mobile commerce”application to the user's client/mobile phone 108 and sign into account102. At this point the user is ready to use network 100. Alternatively,the user can sign-up in a similar fashion through a retailer-branded webinterface or mobile application.

Similarly, to initiate the functionality of network 100, in oneembodiment a merchant first creates a merchant account 104 representingthe corporate entity and then creates store accounts for each physicalstore. FIG. 4 is an overview diagram illustrating a merchant initiatingthe functionality of network 100 of FIG. 1 in accordance with oneembodiment. To accomplish this the merchant would use a web page viamerchant client 121 or other method. In the example of FIG. 4, themerchant has a single store and creates merchant account 104 and a storeaccount of the single location 404 having store hours 405. The merchantwould add information to the store account describing how paymentsshould be handled for that store location. Specifically, the merchantwill designate which acquirer 402 and account 403 processed funds shouldflow into. Acquirer 402 is the merchant's acquirer, also referred to asa payment “processor”. Examples of payment processors include First DataCorp. (“FDC”), Fifth Third Processing Solutions, etc. Account 403 is themerchant's corporate level account or the individual store's account onnetwork 100.

Once the store account is setup, in one embodiment the merchantintegrates a “Beanstalk Library” into the merchant's POS system. TheBeanstalk Library allows the POS system/client 120 to initiatetransactions on network 100, much the same way that these systemsinitiate transactions with a traditional acquirer. In one embodiment,the Beanstalk library combines the functions of the following knownintegration products:

-   -   Credit processing gateways (e.g., First Data Corp, Fifth Third,        etc.);    -   Processing solutions (e.g., Chase Paymentech, Heartland        Processing, etc.);    -   Gift card processing hosts (e.g., First Data Valuelink, Store        Value Solutions (“SVS”), ValuTec, Givex, Mercury Gift Cards,        etc.);    -   Coupon redemption systems (e.g., NCH, Inmar, etc.);    -   Loyalty providers (e.g., City Retail Services, SAP, TSYS, etc.);    -   Voucher providers (e.g., Groupon, Living Social, etc.); and    -   POS hardware platforms (e.g., NCR, Micros, etc).        Once integrated, POS 120 is ready to initiate payments on        network 100. Payments initiated via a beanstalk API are        processed as described by the rules set up in the store account        for the physical store that initiates payment.

Once at least one user and one merchant and store account, and oneissuer has been set up, transactions can occur on network 100. FIG. 5illustrates a user being checked into a store with a store account inaccordance with one embodiment. The example beginning at FIG. 5 is for atransaction with a single item and a single payment instrument.

As shown in FIG. 5, network 100 via the mobile commerce applicationdownloaded on the user's mobile device 108 observes the user's locationand uses this information to determine when the user enters a store thathas a corresponding store account on network 100. The downloaded mobilecommerce application uses GPS signaling in one embodiment to determinewhen the user enters the store by crossing a merchant geo-fence 502. Ageo-fence is a virtual perimeter for a real-world geographic area suchas the store.

To prepare the user to pay at the store, the user mobile applicationsends a check-in request to network 100 indicating that network 100should prepare the user to pay at the store. Network 100 receives thecheck-in request and creates a single-use payment token or “Bean” 510for the user. Network 100 registers the token 510 with the store andreplies to the user's mobile phone 108. If desired by the user, themobile phone 108 can be programmed to buzz or otherwise alert the userto let the user know that they are ready to pay at the store. Similarly,if the manager at the store is looking at POS client 120 or ManagementClient 121, the manager will notice that another user has entered thestore by an indication that pops up on client 120 or 121.

A Bean, such as Bean 510, in general is a session object that capturesthe interaction events between a user and a single store location. Inone embodiment, a Bean object lifecycle begins when a user enters thestore location and ends when a user leaves the store location. Otherlifecycle initialization triggers and ending triggers are possible. Forexample, a Bean could be instantiated in an anonymous transaction by thestore at the time of a transaction initiation, and closed when thetransaction processing is complete. Bean 510 can be used for a singletransaction, or it may be applied to a user session in a store thatspans multiple refunds and purchase transactions.

In the current example where the user purchases a single item, the usermakes the selection of the item and heads to the checkout. FIG. 6illustrates POS client 120 at the merchant and using merchant account104 to checkout the user in accordance with one embodiment. POS client120 displays multiple methods of payment on display 610, includingcredit and debit. One of the options is a “mobile” option indicatingpayment via network 100. As the cashier rings the user up, the userselects the “mobile” option and enters the PIN number in the existingPIN pad.

At this point POS 120 uses the integrated Beanstalk Library toauthenticate the user via the PIN. To achieve this, the POS softwarepasses the user's PIN into the Beanstalk Library and requests anauthentication. The Beanstalk Library sends the request to network 100where the user's PIN is used to validate the user. Once validated, thepayment token 510 (that was created when the user entered the store) isreturned to POS client 120. POS client 120 is now ready for checkout.

FIG. 7 further illustrates the checkout process based on a basket ofgoods selected by the user in accordance with one embodiment. The basketof goods 700 is the line level data of the one or more items that theuser has selected for purchase. Basket of goods 700 includes a fulldescription of each item, including the brand, price, size, stockkeeping unit (“SKU”), etc. In general, the description includes the coreinformation of SKU, price, tax and a list of additional key-valuedescriptors to cover item or merchant specific characteristics such ascolor, category, size, condition, etc. Once the cashier finalizes thetransaction at POS client 120, basket of goods 700 that the userselected is passed into the Beanstalk Library. Basket of goods 700(i.e., line level data) and payment token/Bean 510 are then sent tonetwork 100 for processing.

When the transaction request reaches network 100 it is passed into atransaction engine 810. FIG. 8 illustrates the functionality oftransaction engine 810 in accordance with an embodiment of the presentinvention. The checkout process is based on basket of goods 700 selectedby the user and the corresponding line level data in accordance with oneembodiment. Transaction engine 810 reviews the basket of goods 700 beingpurchased, compares them to the payment instruments in the user's useraccount 102, and selects the correct payment instrument(s) to use. Ifthe user had any item-specific coupons, they would be applied here.However, in this example the user has no coupons and pays the fullamount with the user's debit card.

Once transaction engine 810 has selected the payment instrument (in thisexample, the user's debit card), it looks up the store account'sprocessing preferences. In this example, the store uses First DataCorporation, or other payment processor for processing. Transactionengine 810 sends a request to FDC, or other payment processor orpartner, to put the full total of the transaction (e.g., $5.00) on theuser's debit card and waits for the response.

Assuming the transaction is approved, transaction engine 810 sends asuccess response to POS 120. It then uses the basket of goods to createa digital receipt and notify the user of the purchase and an availablereceipt. Transaction engine 810 similarly creates a receipt for thestore and updates its real-time analytics to reflect these sales.

In a variation of the preceding example, assume the user has selectedmultiple items, and has manufacturer coupons in the user account 102 fortwo of the items: a $10.00 off coupon for “Item A” and a $5.00 offcoupon for “Item B.” In this example, the user's check-in and PINauthentication proceeds in the same manner as disclosed in the aboveexample. However, when the transaction reaches network 100, it isprocessed differently. FIG. 9 illustrates the functionality oftransaction engine 810 with multiple items and multiple payment/tenderoptions in accordance with an embodiment of the present invention. Whentransaction engine 810 compares the basket of goods 700 to the user'suser account 102, which stores the coupons, it matches Item A to one ofthe coupons, and matches Item B to the other coupon. Network 100 is ableto do this because it has received line level data for the basket ofgoods from POS 120. It then applies these payment instruments to thebasket alongside the debit card.

Once the tenders are selected, transaction engine 810 sends threetransaction requests to the acquirer/processor:

-   -   A $10.00 Automated Clearing House (“ACH”) payment from the Item        A manufacturer to the store.    -   A $5.00 ACH payment from the Item B manufacturer to the store.    -   The remainder of the transaction is placed on the user's debit        card.

Transaction engine 810 then waits for the PIN debit transaction tocomplete but not the ACH transactions, since they can take much longerto complete. Receipts are generated and they include information aboutthe redeemed offers. If these offers were part of a specific campaign,the campaign analytics would be updated to reflect this usage.

As disclosed above, network 100 enables merchants to accept any and allforms of tender, to complete complex multi-tender transactions, and toeffectively engage with customers across new channels. Specifically,transaction engine 810 joins user accounts 102, merchant accounts 104and issuer accounts 106 to enable the flexible settlement of any typeand any number of tenders for a single transaction. In turn, thisflexibility empowers merchants to reach customers through new channelswhich require new incentives/tender types for effective engagement. Forexample, mobile web engagement might require the creation anddistribution of mobile advertisements/offers, a “Facebook” engagementmight require Facebook Offers or the distribution of Facebook Credits,and an e-mail marketing campaign might require the creation anddistribution of e-mail offers/Groupon certificates, etc. By supportingany tender type, network 100 effectively unlocks these new channels tomerchants and turns them into powerful and measurable paths to reachcustomers. The resulting platform provides a medium for users andmerchants to seamlessly engage with one another and fosters richmulti-channel relationships. Network 100 allows merchants to promote,distribute, accept and analyze results for new tender types that mostdirectly support their core business.

FIG. 10 is a flow diagram of the functionality of commerce networkmodule 16 of FIG. 1 when providing mobile commerce and conducting mobiletransactions in accordance with one embodiment. In one embodiment, thefunctionality of the flow diagram of FIG. 10 is implemented by softwarestored in memory or other computer readable or tangible medium, andexecuted by a processor. In other embodiments, the functionality may beperformed by hardware (e.g., through the use of an application specificintegrated circuit (“ASIC”), a programmable gate array (“PGA”), a fieldprogrammable gate array (“FPGA”), etc.), or any combination of hardwareand software. The functionality of FIG. 10 can be implement by system 10as shown in FIG. 2, or distributed over multiple system 10s.

At 1002, at least one user account, one merchant account and one issueraccount is established. Each user account holds basic profileinformation, payment preferences and one or more tender instruments,including debit cards, private label credit cards, gift cards, bankaccounts, coupons, offers, loyalty cards, loyalty points, etc. Eachmerchant account holds basic information such as storeaddress/location(s) and merchant acquiring information that defines howpayment should flow to the merchant. Each issuer account may include anauthorization policy, an authorization mechanism and a settlementmechanism for each tender type the issuer supports.

At 1004, a user with a mobile client that has downloaded a mobilecommerce application, such as a smartphone, is detected entering one ofthe stores of the merchant account. In one embodiment, the user isdetected when the user crosses a geo-fence of the store using the user'ssmartphone GPS capability.

At 1006, a token or Bean is created and registered with the store. Anotification is optionally sent to the user indicating that the user nowcan make payments at that store. This is the completion of a first levelof authentication. At this point, the store is able to communicate withthe user via the mobile client, such as providing store information,advertisements, coupons, etc.

At 1008, after the user selects one or more items to purchase that forma basket of goods, the user approaches the store's POS, selects theoption to pay using the mobile commerce network, and enters the mobilecommerce PIN that was associated with the user when the user created theuser account. The PIN is received by the commerce network 100 and isthen authenticated at the network, and the token is sent to the POS inthe store. This is the completion of a second level of authentication.

At 1010, the basket of goods of the user's selections, including linelevel data for all items, is received by the network 100 for processing.

At 1012, the basket of goods is compared with the payment instruments ortender in the user's user account, and the appropriate one or moretenders are selected, validated and authorized to complete the payment(referred to as tender “extraction”). The tenders can include debitcards, credit cards, electronic coupons, electronic group buyinginstruments such as Groupon “deals”/certificates, electronic giftcertificates, etc. When more than one tender can be used to complete thepayment, the “best” tender is selected. For example, coupons or giftcertificates will be used before debit or credit cards, and theremaining balance, if not completely satisfied by the coupon or giftcertificates, can be satisfied by the debit/credit cards.

At 1014, each of the one or more payment requests corresponding to thetenders are sent to the corresponding issuer by initiating/calling theappropriate settlement mechanism for each tender.

Users

As discussed above, every user of network 100 has a user account 102.User account 102 holds basic profile information, global and merchantspecific payment preferences, transaction history, and any number andtype of tender instruments including debit cards, credit cards, privatelabel cards, gift cards, bank accounts, coupons, offers, loyalty cards,loyalty points, etc. The tender instruments in the User account 102 areaccessible at the time of transaction and are used to facilitate paymentin the order/fashion prescribed by the user. The desired use ofinstruments and the order in which they should be used is determined bythe user in a user account preferences file. In one embodiment, thesepreferences may be set once and not modified again, or the user couldmanually adjust these preferences before each transaction.

Users can create, access and manage their user accounts 102 through arange of user clients (e.g., user clients 108, 109, or any devices thatenable the user to interface with network 100). These clients includeweb pages, mobile applications, and tablet interfaces which enable usersto add/delete tender instruments, view transaction history, and performa range of other account management functions. User clients access useraccount data via commerce network 100 and present a consistent set ofinstruments across interfaces. For example, whether a user looks at thecontents of user account 102 on web client 109 or on mobile client 108,the user will see the same set of instruments.

In one embodiment, a primary use for the user clients is adding andmanaging instruments of tender. When a user adds an instrument to useraccount 102, the instrument data is sent to network 100 for securestorage in user account 102. In one embodiment, once instrument data isadded to user account 102, the data exists exclusively in user account102 and is never shared with or stored in any of the clients. However,in one embodiment user account 102 shares instrument references with theuser clients so that the clients can actualize a user interface thatlets users examine, delete and configure the instruments in user account102. Instrument references contain only enough information about theinstrument in one embodiment to allow it to be meaningfully displayed inthe user interface. Because the user clients do not store sensitivetender data, they are not a point of attack from which credentials maybe extracted.

The user clients may also serve as points of user engagement and tenderdiscovery before and after a transaction. For example, a merchant mightpresent an offer to a user when the user arrives at a store to drivesales of an item that is overstocked, or a merchant might provide anoffer attached to a receipt to incentivize the user to return to thestore that same week. In these examples, the user clients also becomechannels for delivering rich personalized experiences and presenting newinstruments of tender.

The user clients, such as user client 108, 109 are merchant-centric.Unlike some prior art mobile wallets that are organized around objecttypes (e.g., payment credentials, offers/coupons, loyalty/reward cards,receipts, etc.), the user clients in accordance with one embodiment areorganized around user/merchant relationships. By default, user accountdata is organized by merchants and this serves as a user client'sorganizing principle. The default view in a user client in oneembodiment is a list of merchants organized by location, favorites orany other arrangement. Users can pivot data around themselves (e.g., toview receipts across all merchants) in another view.

Once a user retrieves a detailed view of a specific merchant, the useris able to see a view of their entire relationship with the merchant.This view, referred to as a “merchant relationship feed” is anintelligent sort of all past, present and potential future user/merchantinteractions. An intelligent algorithm weighs recency, importance andother factors to develop a feed of transactions, offers, rewards, newsand other user/merchant engagement opportunities.

Network 100 enables merchants to reach customers through new channelswhich often require new incentive/tender types for effective engagement(e.g., mobile advertisements/offers for mobile channels, FacebookCredits/Offers for Facebook “likes”, etc.). Across these new channels,users generally engage while they are online and logged into a range ofthird party accounts such as Pinterest, Facebook, Google, Twitter andYahoo. Network 100 allows users to link their user accounts to thesethird party accounts to enable seamless discovery, clipping, sharing andengagement with tender available on these channels. To create this link,in one embodiment network 100 uses “OAuth” to connect user accounts tothese third party account. OAuth is a known open standard forauthorization and provides a process for end-users to authorizethird-party access to their server resources without sharing theircredentials (typically, a username and password pair), using user-agentredirections. In other embodiments, other authorization mechanisms canbe used. A user may elect to link user account 102 to any or all thirdparty accounts made available by network 100.

When a third party account is linked to user account 102, it is granteda set of capabilities to interact with user account 102, which mightinclude adding tender instruments into user account 102. For example, auser who is logged into Yahoo might clip an offer from an email messagedirectly to the user's user account 102. Similarly, when a user account102 is linked to a third party account, with user permission a useraccount 102 may interact with the third party account. For example, auser account 102 might gain access to post something to a user'sFacebook Wall or Twitter Stream. This linking of accounts gives users afederated commerce capability with a broad online presence. Thefederated commerce capability actualizes a chain of authentication sothat no matter what the online context, users are able to save to andpublish from their user account 102.

While the above describes using account federation to add tenderinstruments from Twitter and Facebook, for example, this mechanismextends to any secure online account, including user accounts withfinancial institutions, media outlets and merchants. Therefore, a userlogged in to a merchant or issuer website could similarly push thingslike offers or payment cards into their user accounts.

When a third party account is linked to user account 102, it is granteda set of permissions which can include the ability to add tenderinstruments to user account 102 (including debit cards, private labelcards, gift cards, bank accounts, coupons, offers, loyalty cards,loyalty points etc.). To add instruments to user account 102, thirdparties can interact with a defined set of User Account APIs. With userpermission, these third parties can then push instrument data to theuser account. These APIs can implement using known web servicemechanisms such as Representational State Transfer (“REST”) and datapayloads encoded as JavaScript Object Notation (“JSON”).

If a user is not logged on to network 100 when trying to save a newinstrument to the user account 102, the user will be prompted to loginto network 100 or any third party account. Similarly, if a user isalready logged into a third party account that is not yet federated touser account 102, the user will be prompted to link that account to useraccount 102 or to login using a valid user account 102.

For mobile applications where an application may not use the notion of a“logged in” account (e.g., an advertisement in a video game), the clientapplication exposes local APIs by which an application may pass data tothe client application to be saved. In this embodiment, federatedauthentication is provided by the client installed on the user client.In one embodiment, an intent or uniform resource identifier (“URI”)exchange is used to pass tender data into the client application whichwill receive and save the instrument data.

In one embodiment, user account 102 plays a large role in the settlementof tender at the time of a transaction. When a user makes a purchase,the merchant passes the user authentication token 510, also referred toas a “Bean”, loaded with a basket of goods to network 100. Network 100uses token 510 to access user account 102 and passes the basket of goodsand user account 102 to transaction engine 810 for processing.

Transaction engine 810 examines the basket of goods and full set ofinstruments in user account 102 and applies a business algorithm todetermine which tender instruments to use for the transaction.Transaction engine 810 then initiates the transaction and updates useraccount 102 as necessary. For example, offers that are redeemed tosettle the transaction would be marked as used. Further, if a gift cardis used in a transaction, its balance would be updated in user account102.

The online and federated nature of user account 102 enables it to: (1)gather tender instruments from any online context; (2) make thoseinstruments available for processing at the time of transaction; and (3)update user account 102 after transaction processing so that the usercan immediately see the results of the transaction.

Merchants

As previously discussed, in one embodiment every merchant thatparticipates in network 100 has a merchant account 104. Merchant account104 holds basic profile information, an arbitrary number of stores whichrepresent physical locations for the merchant, geo-fence properties foreach store, merchant acquirers/processors used to finalize settlement ofacceptable forms of tender, etc. In addition, merchant account 104 mayhold any merchant specific business logic that should be applied totransactions.

To provide flexibility, embodiments allow merchants to arrange storesinto arbitrary sets/store groups (e.g., regional groups) to simplify themanagement tasks. A merchant can then use these groups to set storepolicies or publish incentives/offers in varying granularities. Forexample, a merchant could publish a national offer to all stores, a warmweather offer to a group of warm weather stores, a local offer to asingle store or individual offers to specific customers or customergroups, based on any range of demographics, historic purchases, onlinebrowsing, or other characteristics or actions.

Store groups can also be used to delegate administrative permission forthe stores. For example, a regional manager could be given permission toset offers/store policies for a regional store group or a local storemanager could set policies and promotions for one store only.

Merchants can connect to network 100 to authenticate users and initiatetransactions through approved merchant POS clients, such as POS client120. These merchant POS clients may include existing and future POSinfrastructure which is connected to network 100 via merchant APIs 122.In order to authenticate users and initiate transactions, a POS in oneembodiment first authenticates itself to network 100. This initialauthentication includes an exchange of merchant account 104 username,password, and predefined POS identifier (e.g., “Lane 17”). In addition,key material is also exchanged with the POS to more stronglyauthenticate it.

Once authenticated, merchant POS client 120 (via API 122) is used toauthenticate in-store users to network 100. When a user elects to payusing network 100, the user is prompted to enter the PIN on the terminalattached to the POS. For example, the terminal might be a PIN-pad fromVerifone Systems Inc., or a touch-screen PIN-pad when using atablet/mobile POS. Once the PIN is collected, it is sent to network 100where it is compared to the PINs of users checked into the store.Therefore, the PIN is used both to authenticate and disambiguate theuser. If there are multiple users with the same or even similar PINs inthe store, network 100 in one embodiment presents a challenge questionto the user. For example, the user may be asked to enter a date ofbirth, street address number, phone number or other information into thesame terminal. This information would then be similarly passed tonetwork 100 for authentication.

Once a user is authenticated, as described, the POS receives a token, orBean, for the transaction at hand. The Bean is an opaque token thatcarries no intrinsic value and does not return any tender instruments tothe POS. Accordingly, the Bean does not require any PCI securitystandards council or similar level protection by the merchant.

Once the user has authenticated to network 100 via the POS, thecashier/teller at the POS moves forward with the merchant's standardpurchase flow until it is time to complete the transaction. With atraditional transaction, the POS/cashier would send a user instrument(for example a Visa card) and a basket total (for example $100) to anetwork for authorization and settlement. However, for network 100, thecashier sends the token/Bean which includes the complete basket of goodsincluding line level data to network 100. With the basket of goods as aguide, transaction engine 810 then joins the user, merchant and issueraccounts to process the transaction. Once cleared, network 100 returnsan updated receipt to the POS including any price modifications. Thisenables the user have a real-time view of the final purchase price andconfirmation of which instruments were applied to clear the transaction.

Merchants can create, access and manage their merchant accounts 104through a range of merchant clients (e.g., management client 121). Theseclients include web pages, mobile applications, and tablet interfaceswhich enable designated managers to monitor their merchant account,add/delete stores, view transaction history, and perform a range ofother account management functions. A management console providesmerchants with a real-time view of activity in their stores and acrosschannels, such as how many customers are in their stores segmented bycustomer type, subject to user permission, or a customer's individualwish lists or purchase history. Additionally the management consoleprovides a real-time view of purchase velocity, the performance ofpromotional campaigns, and custom monitoring/alerts based on anyinformation available on network 100. The management console alsoprovides access to the business optimization engine, which can be usedto optimize and generate personalized advertising, incentive, andpromotional campaigns across channels to maximize revenue and customerengagement.

Issuers

As disclosed above, every issuer of network 100 has a correspondingissuer account 106. Issuer account 106 details the issuer's tendertypes, and the authorization policy, authorization mechanism, andsettlement mechanism for each form of tender. An authorization policy isa contract that describes how and under what circumstances authorizationfor the tender should occur. An authorization mechanism describes howthe tender should be authorized by the issuer should the authorizationpolicy deem it necessary. Finally, the settlement mechanism describeshow settlement should be actualized for the tender. In one embodiment,network 100 splits the authorization and settlement of tender intoseparate phases to provide a flexible solution capable of handling abroad set of tender types.

For example, if Groupon were to issue an offer that could be redeemed onnetwork 100, Groupon would first create an issuer account or an accountis created on behalf of Groupon. Groupon would specify an authorizationpolicy, an authorization mechanism, and a settlement mechanism for theGroupon tender. Groupon could specify: (1) an authorization policy thatrequired real time authorization for any Groupon tender; (2) anauthorization mechanism that used a web services call to perform theauthorization for the tender; and (3) an ACH settlement mechanism thatused ACH to move the money from Groupon to the merchant. In sometransactions, authorization and settlement could be part of the sameaction for a specific tender type. For example, the authorizationmechanism could be set to null in the issuer account, which would shiftthe responsibility of authorization to the settlement agent.

For traditional payment instruments where the issuer (e.g., a bank) maynot be have a corresponding issuer account on network 100, a delegateissuer account may be automatically configured. For example, a debitcard would use a pre-defined debit Issuer account delegate that wouldspecify authorization and settlement using a traditional debit network.

An issuer can use an issuer management console or other method tofacilitate the setup of issuer accounts 106 and management of theauthorization policy, authorization mechanism, and settlement mechanismfor each tender. The issuer management may also provide real-timeanalytics about issuer tender on network 100, the number of transactionsinflight, the outstanding balance due, settlement, etc.

The authorization and settlement mechanisms specified for use by theissuer can be implemented in a number of ways. Embodiments include a setof issuer APIs 132 and reference implementations that use nextgeneration authorization and settlement mechanisms. For example, whenusing Groupon-based tender, as described above, in one embodimentGroupon would use the authorization mechanism defined in issuer API 132to implement authorization via a web services call.

Validity Score

In one embodiment, network 100 executes a machine learning algorithmover data it collects and combines the results with a predictionalgorithm to provide a “validity score” for all participants and tendersinvolved in a transaction. The validity score is used in conjunctionwith the authorization mechanisms for tender types that support explicitauthorization. If a validity score is insufficient for any tender orparticipant in the transaction, the transaction is either flagged ordeclined.

The validity score allows network 100 to enable settlement using a broadset of instruments. The validity score prediction algorithm uses machinelearning to weigh all aspects of a transaction. As network 100 sees moreand more transactions, the prediction algorithm improves and the machinelearning model becomes trained resulting in improved accuracy. Thequality and quantity of data combined with a scalable machine learningapproach give network 100 the enhanced ability to predict the validityof all components of a transaction. In one embodiment, validity scoringenables network 100 to recognize and flag anything from bad tender, to asuspect user, a bad retail lane, or cashier that exhibits fraudulentcharacteristics. In one embodiment, the validity scoring includesvelocity checks, including frequency of transactions and failedauthentication attempts, location signals including a device locationhistory, and a total amount charged, including single high valuetransactions or high spend per day. The same characteristics can be usedto identify abnormal merchant/POS behavior.

Authentication

As described above, embodiments uses a two factor/level authenticationsystem to verify a user's identity and initiate a transaction. The firstfactor of authentication is a user's geo-location. Specifically, theuser's smartphone or other mobile client must be physically present inthe store to initiate a transaction and the user client (i.e., a mobilecommerce application) must be installed. To make this possible, in oneembodiment a user configures the user client to login to the user's useraccount 102.

Once authenticated, the mobile user client examines all locationinformation and uses a check-in algorithm that runs on the mobile deviceto decide when to send a check-in request to network 100. When the userclient sends the check-in request to network 100, it includes all thelocation information available to the user client. Network 100 analyzesthe request and returns both a decision (checked-in or not), and newdata that will help the user client make better localized decisions inthe future. The dynamic exchange of information between the user clientand network 100 lets the system learn and constantly improve theaccuracy of its geo-fence capability and notice/adjust to any attemptsto fraudulently manipulate location signals.

The second factor of authentication is typically a PIN that the userknows and enters into the POS when the user is ready to initiate atransaction. If for any reason a transaction is flagged/raises fraudconcerns, network 100 can challenge the user to answer questions/provideadditional factors of authentication.

Network 100 uses multiple factors of authentication to verify theidentity of the user in-store. This in-store authentication gates theinitiation of any transaction on behalf of the user. Once a transactionhas been initiated, network 100 seeks to further validate the identityof the user by leveraging machine learning and the user's location,location history, purchase history, and recent behavior to generate avalidity score for the user. If for some reason the user validity scoreis too low, network 100 can issue challenge questions to the user toconfirm the user's identity.

Merchant infrastructure is secured using key exchanges andcashier/teller login to merchant endpoints. For each transaction,network 100 seeks to validate both the authenticity of the merchant'sendpoint and the legitimacy of the behavior originating from thatendpoint. If a merchant endpoint is being used to purchase merchandisethat the merchant does not stock, or a merchant endpoint is being usedto purchase volumes of goods that are unusual, the transactions and/orendpoints can be flagged. Likewise if an invalid or uncommon discountwere applied incorrectly or inappropriately, the transaction, tellerand/or endpoint can be flagged.

To handle transactions and endpoints that were flagged for unusualbehavior, the merchant can specify a policy in merchant account 104. Forslightly odd situations, the merchant could simply request the openingof an audit log. For more serious issues, the merchant could require amanager override for the transaction to complete. Since merchant APIs122 provide merchants with the ability to pass a teller ID along withthe basket of goods, these mechanisms could similarly be used to detectdubious teller behavior.

Authorization

Network 100 sits at the intersection of transactions that span users,merchants and tender types. For each transaction, network 100 considersa wide cross-section of data including basket contents, location, timeof day, consumer purchase patterns and merchant signals like checkoutlane, teller, etc. Network 100 executes a machine learning and apredictive algorithm across this data to derive a validity score asdescribed above. The validity score for all aspects of the transactionincluding the tender is combined with the authorization mechanismsdescribed below to provide robust authorization implementation.

For a tender like ACH that does not have an explicit authorizationmechanism, network 100 internally evaluates whether or not to accept thetender. In this scenario network 100 must decide to accept or declinethe transaction based on the validity scores of the tender and othercomponents of the transaction. Network 100 supports a configurablepolicy that lets the bearer of liability (in the case of ACH, themerchant) configure thresholds for validity scores and dollar values.For example, a merchant might tolerate a range of validity scores forsmall purchases but demand very high validity scores for largepurchases.

In addition to top down validity scoring, issuer defined authorizationpolicies and mechanisms are also used to authorize each tenderinstrument. For example, to determine if a Groupon “certificate” can beused for settlement, network 100 would combine the results of a Grouponauthorization web services call with the tender's validity score.

Traditional instruments like PIN-debit and private label networks havebuilt in authorization mechanisms including PIN, address and/or phonenumber verification. For these traditional forms of payment,authorization is performed at the same time as settlement. Whenauthenticating these forms of tender, network 100 relies on the validityscore calculated for the tender and performs the tender's explicitauthorization as part of settlement. When settling PIN-debit, forexample, the PIN would be passed with the card number to the PIN-debitnetwork as part of the request for settlement. For a private label cardthe settlement mechanism may pass the user's address and phone number tothe private label issuer as additional authorization signals for theprivate label network. For newer tender instruments, the authorizationand settlement will likely be more clearly divided and the settlementmechanism will only perform settlement in one embodiment.

Embodiments can process multiple different forms of tender in a singletransaction. As the number of tenders per transaction increases, keepingtransaction latency low can become increasingly difficult, as thetransaction will be as slow as the slowest form of tender. To authorizethis mixed bag of tenders and ensure timely transactions, embodimentsinclude a number of mechanisms that let network 100 pre-authorizecertain tenders before they are used in a transaction.

Pre-authorization is the act of authorizing a tender without theimmediate expectation of settlement. Pre-Authorization removes thetender issuers from the critical processing path while employing anumber of mechanisms to ensure the tender security is not compromised.The ability to pre-authorize is based on embodiments that decoupleauthorization from settlement. The pre-authorization and transactionhistory of tenders provides critical data for the machine learningalgorithms.

Embodiments may include a number of pre-authorization mechanisms thatare not mutually exclusive. Any number of these mechanisms may be usedalone or in combination to validate a single tender. In addition, thesemechanisms may be used repeatedly during the lifecycle of a tender.

One pre-authorization mechanism authorizes an instrument when it isadded to user account 102. This could be a blocking/gating operation bywhich tender instruments are only allowed in user account 102 afterpassing an authorization check. This is an aggressive form ofauthorization where network 100 validates the health of tender as it isenters the system.

For tenders that have second factors of authentication, anotherpre-authorization mechanism can be used to verify not just the validityof the tender but also the user's ownership of the instrument. For debitcards, network 100 uses the PIN in this capacity. When a user adds adebit card to user account 102, network 100 performs an authorizationnot just to confirm that the card is valid, but also to confirm that itis the owner entering the card.

The pre-authorization on entry to prove validity mechanism describedabove ensures that instruments added to user account 102 are valid onentry, but additional validation may be required as instruments age.Embodiments can scan user accounts and re-authorize instruments thathave not been authorized for some duration of time. For example, if aGroupon voucher/certificate is validated on entry, network 100 couldchoose to re-authorize the voucher after an initial authorizationexpires.

If the user had printed out the Groupon offer and redeemed it manually,then network 100 would receive a “used/not valid” response from Grouponand mark the voucher used in user account 102. Periodic re-authorizationwould be accomplished by rescanning all tender and sending batches oflow priority authorization requests to Groupon.

The check-in aspect of the two-factor authentication system ofembodiments of the present invention provide an opportunity topre-authorize tender in user account 102. When the user checks-in to thestore, network 100 can kick-off a pre-authorization of all the tendersin the user's user account 102 that may be applied at the store the userchecked into. In most cases, the user will be in the store for at leasta few minutes before making a purchase, which provides a window ofopportunity for network 100 to re-authorize and verify the validity ofany instruments that may be used as part of an upcoming transaction.

While the mechanisms described above can improve the latency ofreal-time transaction processing, many of these mechanisms may be usedfor any/all tender types in an account or across network 100 to improvethe security of the system. For example if a number of bad Grouponcertificates were observed, network 100 can interpret this as acompromise of Groupon and choose to re-authenticate all Groupon tendersto assess the situation. Similarly if a specific user was flagged forunusual behavior, network 100 could choose to pre/re-authorize all ofthe user's tenders to see if the user was potentially a fraudster tryingto utilize bad tenders.

Regardless of the validity score or level of pre-authorization, network100 can choose to fully re-authorize tenders at the time of transaction.In the event that authorization cannot be performed in real-time (e.g.,the issuer is experiencing downtime), network 100 can leverage thetender validity score to make an authorization decision about thetender's legitimacy. For example, if an offer were pre-authorized a weekago, and the tender validity score is high, network 100 could proceedwith settlement under the assumption that the tender is good. Thismechanism of falling back to local authorization mechanisms of network100 when real-time authorization fails is referred to as “authorizationfallback.”

Embodiments further include a tunable fallback policy that describes howand when authorization fallbacks should be used. The bearer of liabilityconfigures the fallback policy with acceptable thresholds for tendervalidity scores, time since last successfulauthorization/pre-authorization, etc. In the case of a low value coupon,the expectation would be that the manufacturer (i.e., issuer) would beliable for the coupons and would set relatively permissive thresholdssince the cost of a bad coupon would be very low. Conversely if amerchant accepted private label and shoulder liability, it might setvery high validity thresholds for the private label tender. The merchantcould even set validity thresholds that varied by dollar amount tominimize its risk.

Settlement

To accept payment, in one embodiment merchants must specify an acquirerconfiguration in its merchant account 104. The configuration can be assimple as an acquirer name and account or as complex as a set ofacquirers and accounts and a policy about which acquirers should be usedfor which tender types. This configuration would likely include a rawmerchant account endpoint to be used for transactions that did notexplicitly require an acquirer.

For each tender issued, in one embodiment the issuer must specify asettlement mechanism in the issuer account 106. For legacy tenders,these mechanisms are interactions with legacy networks such as thePIN-debit, private label or credit networks. For newer forms of tender,these mechanisms may be ACH or even direct settlement where/whensupported by issuers. Regardless of the tender, it is the settlementmechanisms affect settlement by initiating the movement of money betweentwo endpoints but never take direct possession of money.

As described above, when a user client initiates a check-in, network 100creates a secure session token or “Bean” that is registered withmerchant account 104. The token contains a reference to the store anduser and the token is referenced within merchant account 104 by theuser's PIN. When the user enters the PIN at the merchant's POS toinitiate a transaction, the PIN is used to lookup the token for theuser. This mechanism therefore uses the PIN both to authenticate theuser and also to disambiguate the user from other in-store users.

When the user enters the PIN to authorize a transaction, a token isreturned from network 100 to the POS. The POS adds the basket of goodsto the token and sends it back to network 100 where the basket is fullyconstructed and the transaction is ready for processing. The token isused by network 100 to facilitate processing. Finally, when thetransaction is complete, the token is turned into a receipt. The tokenis the transactional entity that ties the user, merchant, basket ofgoods and issuers together for the lifecycle of an individualtransaction including post-purchase actions such as returns.

Transaction Engine

Transaction engine 810, as described above, uses user account 102,merchant account 104 and the basket of goods to derive payment from aset of issuer accounts 106. Transaction engine 810 in one embodimentdivides the work of processing a transaction into three distinct phases:a business logic phase, an authentication and authorization phase, and asettlement phase.

The business logic phase is the initial phase of a transaction in whichtransaction engine 810 looks at all instruments in the user's useraccount 102, the tender types the merchant accepts, the items in thebasket of goods, which include line level data, and decides how toprocess the transaction.

Transaction engine 810 first looks at user account 102 and gathers allthe forms of tender. It then organizes the forms of tender based on theuser's stated preference for tender use at the specified merchant. Formsof tender that the user does not want to use are removed from the listof potential tenders.

The list of potential tenders is then filtered based on any restrictionsthe merchant may have. If the merchant for example is not willing toaccept a form of tender it is removed from the list of tenders to beused for the transaction. Merchants set tender acceptance policies andusers may always manually select tender preferences (e.g., universaldefault tender, default tender by merchant, etc.). However, embodimentscan also dynamically and intelligently select user tender for eachtransaction without any required user action.

Transaction engine 810 then applies the tenders to the basket of goodsseeking to honor the order of tender priority and best possible tenderoutcome. This may require relatively complex determinations as sometender types have complex rules and the outcomes of these rules must becompared (i.e., is a “2 for the price of 1” coupon better than a “2 for$5.00 coupon”?). As the basket is processed and tenders are applied, anytender specific policy is also preserved. For example most coupons arenot eligible for stacking and some rewards programs may be applied onlyto certain products.

Transaction engine 810 applies all tenders until the basket of goods isqualified for settlement. This process may take many iterations andinclude many tender types as a single basket may be funded by coupons,loyalty rewards, pre-paid offers, multiple gift cards and a privatelabel card, debit card, etc. Transaction engine 810 in one embodimentcan enable split tender of not just 2 or 3 but an unlimited number ofinstruments.

At this point the business logic phase has completed, the set of tenderinstruments has been chosen, and transaction engine 810 moves onto theauthentication and authorization phase. In this phase, transactionengine 810 leverages the authentication mechanisms described above tovalidate all participants in the transaction, and the authorizationmechanisms described above to authorize all tenders to be used in thetransaction.

To verify the user and merchant, the user and merchant authenticationmechanisms are used, and in the case of insufficient validity correctiveaction is taken. For a weakly authenticated user, challenge questionsare issued, or for a weak merchant endpoint score, the merchantauthentication policy is followed.

To verify the validity of selected tenders, transaction engine 810resolves the issuer account for each tender and performs theauthorization action specified by the authorization policy in issueraccount 106. The authentication and authorization phase ensures that theuser, the merchant, the basket of goods and the tender instruments haveall been validated before moving on to the settlement phase.

In the settlement phase, transaction engine 810 settles the set oftenders that have been specified for the transaction. To settle tenders,transaction engine 810 resolves the issuer account 106 for each tender,looks up the settlement mechanism and executes the settlement.

Network 100 allows merchants to specify a mechanism by which they shouldreceive payment and issuers to specify an agent that should be used tosettle outstanding balances. Network 100 in one embodiment does not takecontrol or hold money at any point during the transaction.

Transaction engine 810 in one embodiment uses a phased approach toprocessing transactions in order to separate business logic,authentication/authorization and settlement from one another. As aconsequence, the authentication and authorization phase of thetransaction validates more than just the tender as transaction engine810 validates all aspects of a transaction regardless of the tenderinstrument(s) used to settle the transaction. Therefore, transactionengine 810 makes it well suited to support tenders with weak or noauthorization mechanism. Conversely, instruments with strongerauthorization mechanisms (e.g., PIN debit) are made increasingly secureby the added layers of validation.

One embodiment allows users to modify tender selection even after atransaction has been settled. For example, if a user accidentallyapplied a 20% off offer to a $10 basket, the user might prefer to savethe offer for the larger transaction. Embodiments let the user modifythe tender selection and re-settle the transaction by choosing to paythe merchant an extra $2 and to have the offer marked as unused.Similarly, if a user wanted to move a purchase from a debit card to aline of credit, or from one line of credit to another line of credit thesame mechanism could be used. This post-settlement modificationmechanism will depend on merchant and issuer policies

As disclosed, embodiments provide a system and commerce network thatintegrates users, merchants and issuers in allowing a user to makepayments to store using a mobile device. Multiple forms of tender may beused to process the payment, and embodiments determine the most suitableforms of payments based on line level data of the basket of goods thatare being purchased. Further, multiple levels of authentication preventfraud and mistakes from occurring.

Several embodiments are specifically illustrated and/or describedherein. However, it will be appreciated that modifications andvariations of the disclosed embodiments are covered by the aboveteachings and within the purview of the appended claims withoutdeparting from the spirit and intended scope of the invention.

What is claimed is:
 1. A computer readable medium having instructionsstored thereon that, when executed by a processor, cause the processorto process a mobile transaction, the processing comprising: detecting amobile device of a user entering a store, wherein the user has acorresponding user account that comprises one or more tenders; creatinga payment token corresponding to the detecting and registering it withthe store; receiving a personal identification number (PIN) from theuser and authenticating the PIN; receiving a basket of goods of one ormore items selected by the user for purchase, wherein the basket ofgoods comprises line level data for the items; selecting one or morepayment tenders from the one or more tenders based at least on the linelevel data; and validating and authorizing the selected payment tenders.2. The computer readable medium of claim 1, wherein the store has acorresponding merchant account that comprises an acquirer and a list ofstores corresponding to a merchant.
 3. The computer readable medium ofclaim 1, wherein the one or more tenders comprises at least one of: adebit card, a credit card, a gift card, a bank account, a coupon, aloyalty card or loyalty points.
 4. The computer readable medium of claim1, wherein the line level data for the items comprises for each item atleast one of a brand, a price, a size, or a stock keeping unit (SKU). 5.The computer readable medium of claim 1, wherein detecting the mobiledevice of the user entering the store comprises detecting a position ofthe mobile device relative to a geo-fence of the store.
 6. The computerreadable medium of claim 1, further comprising transmitting informationto the mobile device after creating the payment token and registering itwith the store.
 7. The computer readable medium of claim 1, wherein theuser account comprises a priority of usage of the one or more tenders,and wherein the selecting is based at least on the priority.
 8. Thecomputer readable medium of claim 1, further comprising: for eachselected payment tender, sending a payment request to a correspondingissuer of the tender.
 9. A computer-implemented method of operating anelectronic commerce network, the method comprising: detecting a mobiledevice of a user entering a store, wherein the user has a correspondinguser account that comprises one or more tenders; creating a paymenttoken corresponding to the detecting and registering it with the store;receiving a personal identification number (PIN) from the user andauthenticating the PIN; receiving a basket of goods of one or more itemsselected by the user for purchase, wherein the basket of goods comprisesline level data for the items; selecting one or more payment tendersfrom the one or more tenders based at least on the line level data; andvalidating and authorizing the selected payment tenders.
 10. The methodof claim 9, wherein the store has a corresponding merchant account thatcomprises an acquirer and a list of stores corresponding to a merchant.11. The method of claim 9, wherein the one or more tenders comprises atleast one of: a debit card, a credit card, a gift card, a bank account,a coupon, a loyalty card or loyalty points.
 12. The method of claim 9,wherein the line level data for the items comprises for each item atleast one of a brand, a price, a size, or a stock keeping unit (SKU).13. The method of claim 9, wherein detecting the mobile device of theuser entering the store comprises detecting a position of the mobiledevice relative to a geo-fence of the store.
 14. The method of claim 9,further comprising transmitting information to the mobile device aftercreating the payment token and registering it with the store.
 15. Themethod of claim 9, wherein the user account comprises a priority ofusage of the one or more tenders, and wherein the selecting is based atleast on the priority.
 16. The method of claim 9, further comprising:for each selected payment tender, sending a payment request to acorresponding issuer of the tender.
 17. A commerce network comprising: afirst level authentication module that detects a mobile device of a userentering a store, wherein the user has a corresponding user account thatcomprises one or more tenders, and creates a payment token correspondingto the detecting and registers it with the store; a second levelauthentication module that receives a personal identification number(PIN) from the user and authenticates the PIN; a payment processormodule that receives a basket of goods of one or more items selected bythe user for purchase, wherein the basket of goods comprises line leveldata for the items, selects one or more payment tenders from the one ormore tenders based at least on the line level data, and validates andauthorizes the selected payment tenders.
 18. The commerce network ofclaim 17, wherein the one or more tenders comprises at least one of: adebit card, a credit card, a gift card, a bank account, a coupon, aloyalty card or loyalty points.
 19. The commerce network of claim 17,wherein the line level data for the items comprises for each item atleast one of a brand, a price, a size, or a stock keeping unit (SKU).20. The commerce network of claim 17, wherein the user account comprisesa priority of usage of the one or more tenders, and wherein theselecting is based at least on the priority.